
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta charset="utf-8" />
    <title>4. Sample architectures &#8212; PSA Crypto API 1.0.1 documentation</title>
    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
    <script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <script type="text/javascript" src="../_static/language_data.js"></script>
    <link rel="author" title="About these documents" href="../about.html" />
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="5. Library conventions" href="conventions.html" />
    <link rel="prev" title="3. Functionality overview" href="functionality.html" />
   
  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
  
  
  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />

  </head><body>
  

    <div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          

          <div class="body" role="main">
            
  <div class="section" id="sample-architectures">
<span id="architectures"></span><h1>4. Sample architectures</h1>
<p>This section describes some example architectures that can be used for
implementations of the interface described in this specification. This list is
not exhaustive and the section is entirely non-normative.</p>
<div class="section" id="single-partition-architecture">
<h2>4.1. Single-partition architecture</h2>
<p>In the single-partition architecture, there is no security boundary inside the system. The
application code can access all the system memory, including the memory used by
the cryptographic services described in this specification. Thus, the
architecture provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">no isolation</span></a>.</p>
<p>This architecture does not conform to the Arm <em>Platform Security Architecture
Security Model</em>. However, it is useful for providing cryptographic services
that use the same interface, even on devices that cannot support any security
boundary. So, while this architecture is not the primary design goal of the API
defined in the present specification, it is supported.</p>
<p>The functions in this specification simply execute the underlying algorithmic
code. Security checks can be kept to a minimum, since the cryptoprocessor cannot
defend against a malicious application. Key import and export copy data inside
the same memory space.</p>
<p>This architecture also describes a subset of some larger systems, where the
cryptographic services are implemented inside a high-security partition,
separate from the code of the main application, though it shares this
high-security partition with other platform security services.</p>
</div>
<div class="section" id="cryptographic-token-and-single-application-processor">
<span id="isolated-cryptoprocessor"></span><h2>4.2. Cryptographic token and single-application processor</h2>
<p>This system is composed of two partitions: one is a cryptoprocessor and the
other partition runs an application. There is a security boundary between the
two partitions, so that the application cannot access the cryptoprocessor,
except through its public interface. Thus, the architecture provides
<a class="reference internal" href="goals.html#isolation"><span class="std std-ref">cryptoprocessor isolation</span></a>. The cryptoprocessor has
some non-volatile storage, a TRNG, and possibly, some cryptographic accelerators.</p>
<p>There are a number of potential physical realizations: the cryptoprocessor might
be a separate chip, a separate processor on the same chip, or a logical
partition using a combination of hardware and software to provide the isolation.
These realizations are functionally equivalent in terms of the offered software
interface, but they would typically offer different levels of security
guarantees.</p>
<p>The PSA crypto API in the application processor consists of a thin layer of code
that translates function calls to remote procedure calls in the cryptoprocessor.
All cryptographic computations are, therefore, performed inside the
cryptoprocessor. Non-volatile keys are stored inside the cryptoprocessor.</p>
</div>
<div class="section" id="cryptoprocessor-with-no-key-storage">
<h2>4.3. Cryptoprocessor with no key storage</h2>
<p>As in the <a class="reference internal" href="#isolated-cryptoprocessor"><span class="secref">Cryptographic token and single-application processor</span></a> architecture, this system
is also composed of two partitions separated by a security boundary and also
provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">cryptoprocessor isolation</span></a>.
However, unlike the previous architecture, in this system, the cryptoprocessor
does not have any secure, persistent storage that could be used to store
application keys.</p>
<p>If the cryptoprocessor is not capable of storing cryptographic material, then
there is little use for a separate cryptoprocessor, since all data would have to
be imported by the application.</p>
<p>The cryptoprocessor can provide useful services if it is able to store at least
one key. This might be a hardware unique key that is burnt to one-time
programmable memory during the manufacturing of the device. This key can be used
for one or more purposes:</p>
<ul class="simple">
<li><p>Encrypt and authenticate data stored in the application processor.</p></li>
<li><p>Communicate with a paired device.</p></li>
<li><p>Allow the application to perform operations with keys that are derived from
the hardware unique key.</p></li>
</ul>
</div>
<div class="section" id="multi-client-cryptoprocessor">
<h2>4.4. Multi-client cryptoprocessor</h2>
<p>This is an expanded variant of the <a class="reference internal" href="#isolated-cryptoprocessor"><span class="std std-ref">cryptographic token plus application
architecture</span></a>. In this
variant, the cryptoprocessor serves multiple applications that are mutually
untrustworthy. This architecture provides <a class="reference internal" href="goals.html#isolation"><span class="std std-ref">caller
isolation</span></a>.</p>
<p>In this architecture, API calls are translated to remote procedure calls, which
encode the identity of the client application. The cryptoprocessor carefully
segments its internal storage to ensure that a client’s data is never leaked to
another client.</p>
</div>
<div class="section" id="multi-cryptoprocessor-architecture">
<h2>4.5. Multi-cryptoprocessor architecture</h2>
<p>This system includes multiple cryptoprocessors. There are several reasons to
have multiple cryptoprocessors:</p>
<ul class="simple">
<li><p>Different compromises between security and performance for different keys.
Typically, this means a cryptoprocessor that runs on the same hardware as the
main application and processes short-term secrets, a secure element or a
similar separate chip that retains long-term secrets.</p></li>
<li><p>Independent provisioning of certain secrets.</p></li>
<li><p>A combination of a non-removable cryptoprocessor and removable ones, for
example, a smartcard or HSM.</p></li>
<li><p>Cryptoprocessors managed by different stakeholders who do not trust each
other.</p></li>
</ul>
<p>The keystore implementation needs to dispatch each request to the correct
processor. For example:</p>
<ul class="simple">
<li><p>All requests involving a non-extractable key must be processed in the
cryptoprocessor that holds that key.</p></li>
<li><p>Requests involving a persistent key must be processed in the cryptoprocessor
that corresponds to the key’s lifetime value.</p></li>
<li><p>Requests involving a volatile key might target a cryptoprocessor based on
parameters supplied by the application, or based on considerations such as
performance inside the implementation.</p></li>
</ul>
</div>
</div>


          </div>
          
        </div>
      </div>
      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
IHI 0086<br/>
Non-confidential<br/>
Version 1.0.1
<span style="color: red; font-weight: bold;"></span>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">4. Sample architectures</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#single-partition-architecture">4.1. Single-partition architecture</a></li>
<li class="toctree-l2"><a class="reference internal" href="#cryptographic-token-and-single-application-processor">4.2. Cryptographic token and single-application processor</a></li>
<li class="toctree-l2"><a class="reference internal" href="#cryptoprocessor-with-no-key-storage">4.3. Cryptoprocessor with no key storage</a></li>
<li class="toctree-l2"><a class="reference internal" href="#multi-client-cryptoprocessor">4.4. Multi-client cryptoprocessor</a></li>
<li class="toctree-l2"><a class="reference internal" href="#multi-cryptoprocessor-architecture">4.5. Multi-cryptoprocessor architecture</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
</ul>
<div id="searchbox" style="display: none" role="search">
  <h3 id="searchlabel">Quick search</h3>
    <div class="searchformwrapper">
    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" />
      <input type="submit" value="Go" />
    </form>
    </div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
      <div class="clearer"></div>
    </div>
    <div class="footer">
      &copy; 2018-2020, Arm Limited or its affiliates. All rights reserved.
      
      |
      Powered by <a href="http://sphinx-doc.org/">Sphinx 2.1.2</a>
      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
      
    </div>

    

    
  </body>
</html>